Now that we explained how SPF and DKIM work, it’s important to mention that both protocols do not provide solid protection against email spoofing because of how the verification process works. As strange as it may sound, DKIM and SPF verification have nothing to do with the FROM header -where spoofing happens. A message can have a spoofed sender in the FROM header and pass SPF / DKIM verification. For example, SPF is ineffective on hosted services like 365, AWS, and Google mail, since all customers use the same SPF record and share sending mail servers.

SPF verification PASS means that the sending server IP address is authorized in the SPF record of the domain in the Return-Path header and not the domain in the From header. Return-Path is the email address that receiving servers use to notify the sending mail server of delivery problems, like bounces.

 

Figure - zoom in

 

On the other side, DKIM verification PASS means that the received message was digitally signed by the private key corresponding to the public key published on the DNS server of the domain in the DKIM signature header (d=) tag. Like SPF, it has nothing to do with the domain in the From header.

 

Figure - zoom in

 

From a security/spoofing perspective, we are concerned more with the FROM header-which displays the sender’s name and email address- because this is what recipients see in their email clients. As with the following example, the FROM header was manipulated to spoof the identity of Amazon support.

 

Figure - zoom in

 

SPF and DKIM limitations created the need to fill this gap and protect against email spoofing, mainly the FROM header. This is what the DMARC protocol does.

 

DMARC -Domain-based Message Authentication, Reporting & Conformance- is an email authentication, policy, and reporting protocol. It uses SPF and DKIM to verify that the address in the ‘From’ header is the actual sender of the message. An email to pass DMARC must either pass and align SPF OR pass and align DKIM. We explained earlier what SPF/ and DKIM PASS mean. But what about SPF/DKIM alignment?

 

Aligned SPF means the domains in both “Return-Path” and “From” headers match. Aligned DKIM means the domains in the “DKIM signature d=” header and “From” header match.

 

Figure - zoom in

 

By requiring either SPF or DKIM to be aligned, DMARC offers robust protection against email spoofing. 

DMARC also provides security analysts with two critical things that SPF and DKIM do not offer:

• Control: With SPF and DKIM, it is up to the receiving server to decide what to do with messages that fail SPF/DKIM verification. DMARC takes this further and provides domain owners complete control to set a policy to reject or quarantine emails that fail the verification process. It lets you tell receiving mail servers how you want them to behave if they received a spoofed message from your domain.
• Visibility: DMARC provides domain owners with visibility and reports on who is sending emails from their domains, ensuring legitimate emails only are received. It provides a way for the receiving server to report messages that pass or fail the DMARC evaluation to the sending domain.

 

DMARC records are published as TXT records in the DNS server, just like DKIM and SPF. To check the DMARC record for a domain, we query the DNS server for _dmarc.<domain>. Look at a live example and check the DMARC record for nsa.gov. We can do this by executing the following command

dig _dmarc.nsa.gov TXT | grep dmarc

 

Figure - zoom in

 

As we can see, the DNS server for nsa.gov responded with the DMARC record for the nsa.gov domain. Let’s break it down:

• v=DMARC: The DMARC version should always be “DMARC1”. A wrong or absent DMARC version tag would cause the entire record to be ignored.
• p=quarantine: Policy applied to emails that fail the DMARC check. Available options are: “none”, “quarantine”, and “reject”. “none” is used to collect feedback and gain visibility into email streams without impacting existing flows. “quarantine” allows mail receivers to treat email that fails the DMARC check as suspicious. They will often end up in your SPAM folder. “reject” outright rejects all emails that fail the DMARC check.
• fo=1: Forensic reporting options. Available options are: “0”, “1”, “d”, or “s”.
  •  “0” generates reports if both SPF and DKIM fail.
  •  “1” generates reports if SPF or DKIM fails.
  •  “d” generates reports if DKIM only failed verification.
  •  “s” generates reports if SPF only failed verification.
• rua=mailto:DMARC_REPORTING@nsa.gov: tells receiving servers where to send aggregate reports. Aggregate reports are very important and contain the authentication status for SPF, DKIM, and DMARC. These reports don’t have sensitive information from the email itself. Instead, it includes diagnostic information like the IP that sent the message and whether SPF/DKIM verification passed or failed.
• ruf=mailto:DMARC_REPORTING@nsa.gov: tells receiving servers where to send forensic reports. A more detailed reporting option is intended to provide domain owners with redacted email copies that failed the DMARC check.
• rf=afrf: The reporting format for individual Forensic reports. Available options are: “afrf”, “iodef”.
• pct=100: tells the receiving server the percentage of incoming mails to apply DMARC policy on that domain (for messages that fail verification). In this example, NSA is telling receiving servers to quarantine 100% of messages from @nas.gov if they fail DMARC.

Let’s look at another example. Here is the DMARC record for google.com

 

Figure - zoom in

 

Here we can see that Google has a REJECT policy which means that any receiving server should drop all messages coming from @google.com if they fail DMARC. Unlike nsa.gov, where the policy is set to Quarantine.